Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-153.txt

Text File | 1994-12-08 | 48.8 KB | 1,298 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 02 Aug 92       Volume 1 : Issue 153

Today's Topics:

    TextEdit question
    A bunch of questions
    Inside MacIntosh vol. VI
    Some details on tail patching under System 7
    new version of ResEdit?
    ListManager question
    How Would The Ideal Application Framework Do This?
    Prototyper - summary of responses



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Jari Multisilta)
Subject: TextEdit question
Date: 18 Jun 92 11:49:32 GMT
Organization: University of Tampere, Finland

I am trying to write a simple text editor which has also capability
to display index characters (in math. x power 2, for example).

Does anybody know what is the best way to implement this feature using
TextEdit routines? I have tried to use GetStylScrap function to get current
selectionUs ScrpSTTable and then adjust scrpHeight and scrpAscent fields.
Finally I have set the ScrpSTTable to current selection by using SetStylScrap
procedure. This seems to have no effect!

What should I do to get this work? Thanks of any help


Jari Multisilta
Researcher
Tampere Univ. of Technology
P.O. Box 692
SF-33101 Tampere, Finland

Email: [e-mail]




+++++++++++++++++++++++++++

From: [e-mail] (Stephen Uitti)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Thu, 18 Jun 1992 17:31:29 GMT

In article <[e-mail]> [e-mail] (Jari Multisilta) writes:
>I am trying to write a simple text editor which has also capability
>to display index characters (in math. x power 2, for example).
>
>Does anybody know what is the best way to implement this feature using
>TextEdit routines? I have tried to use GetStylScrap function to get current
>selectionUs ScrpSTTable and then adjust scrpHeight and scrpAscent fields.
>Finally I have set the ScrpSTTable to current selection by using SetStylScrap
>procedure. This seems to have no effect!
>
>What should I do to get this work? Thanks of any help

TESetStyle has a bug.  See Tech note 131.

The workaround from Tech note 131 is to call TESetStyle twice.

void AddText(char *text, long length, TextStyle *newstyle)
{
    TextStyle tmpStyle;
    short *shortp;

    tmpStyle = *newstyle;    /* structure copy */
    shortp = (short *)&tmpStyle.tsFace;
    *shortp = 0;        /* zero the whole word, not just the byte */
    TESetStyle(doAll, &tmpStyle, FALSE, myTE);     /* myTE is destination */
    TESetStyle(doAll, newstyle, FALSE, myTE);    /* set the style */
    /* code to grow the TE, handle errors, and insert the text */
    /* ... */
}

Stephen.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 26 Jun 92 19:29:56 GMT

In <[e-mail]> [e-mail] (Jari Multisilta) writes:

>I am trying to write a simple text editor which has also capability
>to display index characters (in math. x power 2, for example).
>Does anybody know what is the best way to implement this feature using
>TextEdit routines?


Perhaps it would be much simpler if you were to simply create your own
font that contained all characters you need.  Include that in your app's
resource fork, then you'll be (virtually) guranteed that even if TextEdit
mutates into something very different, your characters will still be
okay.  It would also make your program easier to localize (if the need
to ever came up).

Just a thought...

    - Scott

---------------------------

From: [e-mail] (Eggert Bjarni Thorlacius)
Subject: A bunch of questions
Date: 18 Jun 92 13:36:43 GMT


Hello all.

I've been gathering up a pile of questions recently and I'm posting them all
together to save bandwidth :-)

1.  Is there a way to see if a machine can turn itself off from software?

2.  Is there a way to get QuickTime not to dither movies?  I'm writing
    a program to make an animation movie, and do not want it to be dithered.
    I tried drawing into an 8 bit GWorld(same depth as the screen), but that
    didn't work.

3.  Which compressor should I use for animations?  What is it's codecType?

4.  Where can I get the QuickTime documentation?( I bet you saw that one
    coming :-)

5.  Is there a version of The Programmers Online Companion that includes IM 6?

6.  I remember hearing somewhere about an e-mail address to which you can send
    stuff and it will be put on all ftp servers and posted on comp.binaries.mac
    I think it was mac-gifts@something  Does anyone remember the rest?


Thanks in advance,

- --------------------------------------------------------------------------------
Eggert Thorlacius    | Disclaimer of the week:
University of Iceland    |     Oh, sorry, I didn't mean that

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 26 Jun 92 04:09:33 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Eggert Bjarni Thorlacius) writes:
>
> 1.  Is there a way to see if a machine can turn itself off from software?

I don't believe so.  You probably have to use the "informational" machine
identifier from Gestalt.

> 4.  Where can I get the QuickTime documentation?( I bet you saw that one
>     coming :-)

It's on the QuickTime Developer CD.  I don't know if you can still get this,
but APDA would be the place.  Check their catalog.

> 5.  Is there a version of The Programmers Online Companion that includes IM 6?

Not yet.  I don't know if it is even planned.  Currently there are no online
versions of IM6 except for the stack on the developer CD, and it's not really
worth the effort, IMHO.

> 6.  I remember hearing somewhere about an e-mail address to which you can send
>     stuff and it will be put on all ftp servers and posted on comp.binaries.mac
>     I think it was mac-gifts@something  Does anyone remember the rest?

[e-mail] is the most recent one, I believe.  There used
to be one at rascal, but Werner's plum run out of time to maintain it.

Jon


+++++++++++++++++++++++++++

From: [e-mail] (Mike Dodd)
Date: Fri, 26 Jun 1992 05:29:54 GMT
Organization: Apple Computer Inc.

> > 5.  Is there a version of The Programmers Online Companion that includes IM 6?
>
> Not yet.  I don't know if it is even planned.  Currently there are no online
> versions of IM6 except for the stack on the developer CD, and it's not really
> worth the effort, IMHO.
>
well, actually, there is a Programmers Online Companion database file that includes IM 6...
but it wasn't done by them. the file isn't great (doesn't include volume or page numbers
for any of the calls, even the IM I-V calls .... has a few other weird problems), but is
mostly sound.

i might be able to post it somewhere if someone would like to give me a clue as to where
would be a good place....


- -Mike Dodd-
Apple Computer
** What I say is my opinion. Not Apple's. **


+++++++++++++++++++++++++++

From: [e-mail] (Jerry Lobdill)
Date: 28 Jun 92 12:46:52 GMT

'Twas a dark and stormy night when JP rose and said...

  JP> From: [e-mail] (Jon Pugh) Newsgroups: comp.sys.mac.programmer
  JP> Organization: Apple Computer, Inc.
  JP>
  JP> In article <[e-mail]>, [e-mail] (Eggert Bjarni
  JP> Thorlacius) writes:
  JP>
  > 1.  Is there a way to see if a machine can turn itself off from
  > software?
  >
  JP> I don't believe so.  You probably have to use the "informational"
  JP> machine identifier from Gestalt.
  JP>
  > 4.  Where can I get the QuickTime documentation?( I bet you saw that one
  > coming :-)
  >
  JP> It's on the QuickTime Developer CD.  I don't know if you can still get
  JP> this, but APDA would be the place.  Check their catalog.
  JP>
  > 5.  Is there a version of The Programmers Online Companion that includes
  > IM 6?
  >
  JP> Not yet.  I don't know if it is even planned.  Currently there are no
  JP> online versions of IM6 except for the stack on the developer CD, and
  JP> it's not really worth the effort, IMHO.
  JP>
  > 6.  I remember hearing somewhere about an e-mail address to which you
  > can send stuff and it will be put on all ftp servers and posted on
  > comp.binaries.mac I think it was mac-gifts@something  Does anyone
  > remember the rest?
  >
  JP> [e-mail] is the most recent one, I believe.
  JP> There used to be one at rascal, but Werner's plum run out of time to
  JP> maintain it.
  JP>
 *************

Craig Vaughan's MacWoof will Shutdown and Restart the Mac from software. He's
the moderator of the Macwoof conference.

***************

---------------------------

From: [e-mail] (Stuart Allen)
Subject: Inside MacIntosh vol. VI
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Thu, 18 Jun 1992 15:11:06 GMT

If I am concerned only with system 7, should I get
any of the volumes of Inside MacIntosh other than VI?
What (pertaining to system 7) is in those earlier volumes that
is not in volume VI?

Thanks


+++++++++++++++++++++++++++

From: [e-mail] (The Web)
Date: 19 Jun 92 09:14:38 GMT
Organization: U.C. Berkeley Open Computing Facility

What (pertaining to system 7) is in those earlier volumes that
is not in volume VI?

- ------


If you do not own volumes I, II, IV and (maybe) V, you will need them.  Anyhting
that is common to both system 6 and 7 is in these books.  You just can't do
anyhting more exciting than 'Hello World' without them.

Sorry.

- -E. Wylie

+++++++++++++++++++++++++++

From: [e-mail] (Mark Hayes)
Date: 19 Jun 92 12:51:57 GMT
Organization: Boston University, Boston, MA, USA

It should be noted here that (according to my copy of "Macintosh C
Programming Primer" by Mark & Reed) Apple is planning to release
a completely revamped "Inside Macintosh" series this fall, so it
might be a good idea for would-be developers to hold off on purchasing
the whole shootin' match until then. Meanwhile, in case there's
anyone out there who doesn't know, let me mention that Volumes I - V
of the current IM are available from ftp.apple.com as an enormous
HyperCard stack. It's a little hard to read on the screen, but I
just print out a section if I need to read it closely. It's really
great, if you can spare the 10 megs on your hard disk!




+++++++++++++++++++++++++++

From: [e-mail] (Eric Brunson)
Date: 19 Jun 92 13:19:50 GMT
Organization: Vista-Chrome Incorporated

[e-mail] (Stuart Allen) writes:

>If I am concerned only with system 7, should I get
>any of the volumes of Inside MacIntosh other than VI?
>What (pertaining to system 7) is in those earlier volumes that
>is not in volume VI?

>Thanks

Don't let the imposing size of this tome fool you, the only thing in
volume VI is stuff that has changed from system 6 to system 7.  You
really need the entire library to be complete.  An interim, stop-gap
alternative to buying vols. I-V is the Think Reference, online manual
or the shareware Inside Mac DA ( pitched mine when I bought the Think
version so I don't know the author, and there used to be a copyright
debate about whether the author was allowed to charge a fee for the
material that he copied verbatum from IM.  I guess this was resolved
since he has since come out with a version 2. )  I'm not implying that
either of these is a substitute to the actual volumes for several reasons
but the set of all 6 books can set you back a bit all in one go.

Sincerely,
- --
Eric Brunson               These opinions are mine alone,
[e-mail]         but they could be yours for a low monthly fee!
"He's a genius, eh, he hooked up our stereo."

+++++++++++++++++++++++++++

From: [e-mail] (John Andrews)
Organization: UIUC Center for Supercomputing Research and Development
Date: Fri, 19 Jun 92 18:20:51 GMT

[e-mail] (Eric Brunson) writes:

[e-mail] (Stuart Allen) writes:

>If I am concerned only with system 7, should I get
>any of the volumes of Inside MacIntosh other than VI?
>What (pertaining to system 7) is in those earlier volumes that
>is not in volume VI?

First, I would recommend waiting until the rumored revised set of
manuals comes out later this year, since IM combined with all tech notes
has become unwieldy.

If you can't wait, you need (in rough order of usefulness):

Volume I (most useful)
Volume VI, Volume II (very useful)
Volume IV, Volume V (fairly useful, depending on what you are doing)


I think Volume III is totally obselete if I'm not mistaken, and there is
no reason to buy it.

- --
John Andrews ([e-mail]) "He who dies with the shortest .sig, wins"
Graduate Research Assistant, Center for Supercomputing R&D, Urbana, IL

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 26 Jun 92 04:02:38 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Stuart Allen) writes:
>
> If I am concerned only with system 7, should I get
> any of the volumes of Inside MacIntosh other than VI?
> What (pertaining to system 7) is in those earlier volumes that
> is not in volume VI?

Everything.

IM 6 is only the _additional_ stuff for System 7.  None of the basic stuff
is repeated.  You need _all_ 6 volumes.

Of course you could wait for the new improved Inside Mac, but we'll be old
by then ;) and you want to write code now.

Jon


---------------------------

From: [e-mail] (Greg L. Anderson)
Subject: Some details on tail patching under System 7
Date: 18 Jun 92 16:55:13 GMT
Organization: Apple Computer Inc, Cupertino, CA

It appears that many people are still uncertain if it is okay to install
a tail patch under System 7.  Here are a few words on the subject from
some mail I sent to Bill Walburg regarding his question on tail patching.

- ----

To the best of my knowledge, you may Tail-patch every trap in System 7
_except_ for FrontWindow.  I'm not sure why that one is special; Dean
Yu just said "don't do it".

System 7 has a new improved SetTrapAddress/GetTrapAddress mechanism
that allows tail patching.  This mechanism did not exist in System 6.
It works through a little bit of magic.  System come-from patches
(the icky bug fixes that made tail patching inadvisable under System 6)
are installed in a special magic way by the system.  They also include
special magic that allows the system to determine if there is a
come-from patch at the head of the trap pointer, and if there is, the
system can get _and change_ the address of the routine that will be
executed after the come-from patch.

If your trap patch is not installed using the special system magic
(and it shouldn't be), then GetTrapAddress will return to you the address
of the first function _after_ all of the come-from patches, and
SetTrapAddress will install your routine _after_ all of the come-from
patches.  Thus, your trap patch will not be "in the way" when the come-from
patch is snooping up the stack.

- ----

Don't try this under any System prior to System 7.

=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Macintosh System Software      O O  is  ideal  O O
[e-mail]       Finder Team                     O     shape     O
=====================   ===========================   =====================

+++++++++++++++++++++++++++

From: [e-mail] (Dean Yu)
Date: 27 Jun 92 01:16:18 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Greg L. Anderson)
wrote:
> To the best of my knowledge, you may Tail-patch every trap in System 7
> _except_ for FrontWindow.  I'm not sure why that one is special; Dean
> Yu just said "don't do it".

  The mythical Layer Manager has a come from patch on FrontWindow that will
not call through in some cases, so if you patch FrontWindow, your patch may
not fire.  It's probably not worth the effort to try to work around it.

- -- Dean Yu
   Blue Meanie, Negative Ethnic Role Model, etc.
   Apple Computer, Inc.

---------------------------

From: [e-mail] (Daniel Sears)
Subject: new version of ResEdit?
Date: Sat, 20 Jun 92 22:02:40 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

New versions of ResEdit used to appear very frequently.  But now we're
approaching the first birthday of ResEdit 2.1.1 (7/10/92).  Apple is
coming out with a second edition of the ResEdit reference manual this fall
(frankly, the manual needs improvement much more than the program) and the
Addison-Wesley catalog mentions version 2.1 for this book.  But is there a
new release in sight?  Perhaps a *maintenance* release?

My problem is that ResEdit 2.1.1 has robustness problems running under
System 7.0.1 + Tuneup 1.1.1 in 24-bit mode.  Using it in 32-bit mode is
completely hopeless.  And these problems are more common under 6.0.8.
They usually show up when I try to save a DITL resource and then close it.
I've gotten into the habit of closing all my resources and then saving the
resource file, but this is a pain.

I know that I should go out and spend $250 on Resourceror, but for the
kinds of things I do, it just isn't worth it.

- --Dan
- --
Daniel Sears

E-mail:     [e-mail]
Phone:      [phone]
Address:    2440 16th Street #283
            San Francisco, CA 94103-4211

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 21 Jun 92 05:32:20 GMT
Organization: Peirce Software


In article <m#nl56#[e-mail]> (comp.sys.mac.programmer,comp.sys.mac.system), [e-mail] (Daniel Sears) writes:
> New versions of ResEdit used to appear very frequently.  But now we're
> approaching the first birthday of ResEdit 2.1.1 (7/10/92).  Apple is
> coming out with a second edition of the ResEdit reference manual this fall
> (frankly, the manual needs improvement much more than the program) and the
> Addison-Wesley catalog mentions version 2.1 for this book.  But is there a
> new release in sight?  Perhaps a *maintenance* release?
>
> My problem is that ResEdit 2.1.1 has robustness problems running under
> System 7.0.1 + Tuneup 1.1.1 in 24-bit mode.  Using it in 32-bit mode is
> completely hopeless.  And these problems are more common under 6.0.8.
> They usually show up when I try to save a DITL resource and then close it.
> I've gotten into the habit of closing all my resources and then saving the
> resource file, but this is a pain.

Could it be some incompatable INIT maybe?  I use ResEdit (almost daily)
and do a lot of DITL editing with it, among other things.

I've had very few problems with 2.1.1 - I can't remember the last time
it crashed on me and I'm running 7.0.1 + Tuneup on a Q900.

I do agree that it would be nice to see some new stuff in ResEdit.

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --  Makers of...        --   San Jose, California USA 95117
- --                      --   voice: [phone] fax: [phone]
- --     SMOOTHIE         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 22 Jun 1992 12:49:26 GMT

Not a single problem with ResEdit here, although, my version has numerous
version numbers inside of it, I'm not sure what version I'm using!

Anyway, Resorcerer (notice, this is the _correct_ spelling) is a great
product. I use it every single day and really like it. The only thing I
use ResEdit for is it's color icon editors. But Resorcerer has promised
that I won't have to suffer much longer ;)

- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP
- -- asm.comm.networks.cool tunes...

+++++++++++++++++++++++++++

From: [e-mail] (Stephen Uitti)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Mon, 22 Jun 1992 15:17:00 GMT

In article <m#nl56#[e-mail]> [e-mail] (Daniel Sears) writes:
>New versions of ResEdit used to appear very frequently.  But now we're
>approaching the first birthday of ResEdit 2.1.1 (7/10/92).  Apple is
>coming out with a second edition of the ResEdit reference manual this fall
>(frankly, the manual needs improvement much more than the program) and the
>Addison-Wesley catalog mentions version 2.1 for this book.  But is there a
>new release in sight?  Perhaps a *maintenance* release?
>
>My problem is that ResEdit 2.1.1 has robustness problems running under
>System 7.0.1 + Tuneup 1.1.1 in 24-bit mode.  Using it in 32-bit mode is
>completely hopeless.  And these problems are more common under 6.0.8.
>They usually show up when I try to save a DITL resource and then close it.
>I've gotten into the habit of closing all my resources and then saving the
>resource file, but this is a pain.

I found ResEdit 2.1.1 crashing when doing almost anything with a DITL.
I "upgraded" to 2.1, which solved my problems.

>I know that I should go out and spend $250 on Resourceror, but for the
>kinds of things I do, it just isn't worth it.

There's something to be said for going commercial.  We have Resourceror
in house, but I haven't needed anything more than ResEdit 2.1.

Stephen.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (David "Lefty" Schlesinger)
Date: 22 Jun 92 19:55:22 GMT
Organization: Apple Computer, Inc.

In article <m#nl56#[e-mail]>, [e-mail] (Daniel Sears)
wrote:
>
> My problem is that ResEdit 2.1.1 has robustness problems running under
> System 7.0.1 + Tuneup 1.1.1 in 24-bit mode.  Using it in 32-bit mode is
> completely hopeless.  And these problems are more common under 6.0.8.
> They usually show up when I try to save a DITL resource and then close it.
> I've gotten into the habit of closing all my resources and then saving the
> resource file, but this is a pain.

I'm very surprised to hear this.  I use ResEdit in just this environment on
a many-times-daily basis (7.0.1+1.1.1, 32-bit addressing), and I haven't
experienced any problems.

- --
David "Lefty" Schlesinger ([e-mail])
AppleTalk Bug Wrangler
Apple Computer, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Jim Matthews)
Date: 23 Jun 92 12:51:10 GMT
Organization: Dartmouth College, Hanover, NH

Stephen Uitti writes
> I found ResEdit 2.1.1 crashing when doing almost anything with a DITL.
> I "upgraded" to 2.1, which solved my problems.

Are you running Super Boomerang 3.0 by any chance?  There's an
incompatibility between SB and the ResEdit DITL editor.  One workaround is
to perform a clipboard operation (e.g. Copy) before any DITL editing;
another is to get SB 3.0.1, which fixes this problem.

Jim Matthews
Dartmouth Software Development

+++++++++++++++++++++++++++

From: [e-mail] (Stephen Uitti)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Tue, 23 Jun 1992 18:58:54 GMT

In article <[e-mail]> [e-mail] (Jim Matthews) writes:
>Stephen Uitti writes
>> I found ResEdit 2.1.1 crashing when doing almost anything with a DITL.
>> I "upgraded" to 2.1, which solved my problems.
>
>Are you running Super Boomerang 3.0 by any chance?  There's an
>incompatibility between SB and the ResEdit DITL editor.  One workaround is
>to perform a clipboard operation (e.g. Copy) before any DITL editing;
>another is to get SB 3.0.1, which fixes this problem.

I don't run Super Boomerang.  My most intrusive system things
are 8*24GC (my video board), and ethernet.

We've had problems with ResEdit 2.1.1 on our Mac IIsi, Mac IIci, Mac IIfx,
and Mac IIcx hardware, now all running some verson or other of System 7.

Stephen.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Nigel Stanger)
Date: 24 Jun 92 04:25:24 GMT
Organization: University of Otago, Dunedin, New Zealand

[e-mail] (Daniel Sears) writes:
>
> My problem is that ResEdit 2.1.1 has robustness problems running under
> System 7.0.1 + Tuneup 1.1.1 in 24-bit mode.  Using it in 32-bit mode is
> completely hopeless.  And these problems are more common under 6.0.8.
> They usually show up when I try to save a DITL resource and then close it.
> I've gotten into the habit of closing all my resources and then saving the
> resource file, but this is a pain.

You don't happen to be using the "Default CDEF" (written by
someone whose name eludes me at the moment), which automagically
draws the default outline around any button with an @ appended to
it's name? I used to have exactly the problem that you describe,
and I discovered that it was because of this CDEF -- for some
reason, the DITL editor in ResEdit really hates it. It works fine
elsewhere though. I removed it from all my resource files and the
problem went away

- ----------------------------------------------------------------------
Nigel Stanger,                  Internet: [e-mail]
University of Otago,            Phone: [phone]
Dunedin, NEW ZEALAND.           Fax:   [phone]
Useful tip #82913: Do not shave with a hedge trimmer.

---------------------------

From: Stephan Bublava <[e-mail]>
Subject: ListManager question
Organization: Fachschaft Informatik, TU Wien
Date: Sun, 21 Jun 1992 03:05:45 GMT

To extract data from a cell the ListManager provides the procedure
(according to Inside Macintosh):

    PROCEDURE LGetCell (dataPtr: Ptr; VAR dataLen: INTEGER;
                        theCell: Cell; lHandle: ListHandle);

    Given a cell in theCell, LGetCell copies the cell's data to the
location
    specified by dataPtr; dataLen is the maximum number of bytes allowed.
If
    the data is longer than dataLen, only dataLen bytes are copied into
the
    location specified by dataPtr. If the data is shorter than dataLen,
                                                  ^^^^^^^
    dataLen is set to the true length of the cell's^data.


Since I do not know in advance how long the data in a given cell is, I
must do something like this:

    len := MAXINT;              (* !! maximum possible length of data *)
    dataPtr := NewPtr (len);
    LGetCell (dataPtr, len, theCell, theList);
    SetPtrSize (dataPtr, len);

Now this is stupid (at least in my opinion) since i have to allocate
MAXINT bytes for every cell that I extract from the list.

After installing EvenBetterBusError :-) I tried:

    len := MAXINT;
    LGetCell (NIL, len, theCell, theList); (* len will be set to real length
*)
              ^^^
    dataPtr := NewPtr (len);
    LGetCell (dataPtr, len, theCell, theList);

Crash! 8-( ListManager writes to memory location zero.

Is there any better solution to determine the length of data in a given
cell ?????


Stephan Bublava
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Christoph Sold)
Organization: Universitaet Kaiserslautern
Date: Fri, 26 Jun 1992 15:44:13 GMT

In article <[e-mail]>
 Stephan Bublava <[e-mail]> writes:

>To extract data from a cell the ListManager provides the procedure
>(according to Inside Macintosh):

>        PROCEDURE LGetCell (dataPtr: Ptr; VAR dataLen: INTEGER;
>                            theCell: Cell; lHandle: ListHandle);

>    Given a cell in theCell, LGetCell copies the cell's data to the
>    location specified by dataPtr; dataLen is the maximum number of
>    bytes allowed.
>    If the data is longer than dataLen, only dataLen bytes are copied into
>    the location specified by dataPtr. If the data is shorter than dataLen,
>                                                      ^^^^^^^
>    dataLen is set to the true length of the cell's^data.


>Since I do not know in advance how long the data in a given cell is, I
>must do something like this:

>        len := MAXINT;                  (* !! maximum possible length of data *)
>        dataPtr := NewPtr (len);
>        LGetCell (dataPtr, len, theCell, theList);
>        SetPtrSize (dataPtr, len);
>
>    [...]
>
>Crash! 8-( ListManager writes to memory location zero.

>Is there any better solution to determine the length of data in a given
>cell ?????

Yes!
A very easy solution is to allocate a handle which is surely longer than the
longest data you ever store in a cell. Then do a

    myLargeStorage := NewHandle(kMaxSizeNeeded);
    {error checking should be done here}
    itsSize := kMaxSizeNeeded;
    LGetCell(myLargeStorage^, itsSize, theCell, theList);


Now you've got your data handly. The reminder is simple:

    myFinalStorage := myLargeStorage;
    HandToHand(myFinalStorage); {create a copy of the data needed}
    SetHandleSize(myFinalStorage, itsSize); {truncate the handle here}

- -Christoph

P.S.: Your code fragent will crash because of two reasons: The toolbox
assumes your parameters will be right anytime you pass them. If you pass NIL
as dataPtr, memory at location zero ff. will be overwritten.
Second, the List Mgr always writes max the number of bytes you pass as
dataLen. Thus, if you allocate *no* bytes, but tell you've allocated maxInt
bytes in dataLen, things will go very wrong.

Christoph P. Sold                   CATS Software GmbH
                                    Mussbacher Landstr.2
                                    W-6730 Neustadt (Weinstrasse)
[e-mail]     Germany

"If an apple is fun, what the heck is an appletree?"

---------------------------

From: [e-mail] (P. Hawthorne)
Subject: How Would The Ideal Application Framework Do This?
Date: 22 Jun 92 09:16:33 GMT
Organization: Reed College, Portland OR


   Say the application involves a tricky set of menus. Updating menus
when the user goes to make a menu selection could result in an
unacceptably long delay in some situations. Updating menus as the
session progresses requires watching out for many circumstances, such as
(but by no means restricted to) whether the document has been saved
since it was last changed, or whether there is a current selection.
   Perhaps the flow of control in the application is partly governed by
the state of the menus, for instance, by preventing the user from
issuing a command when there is not enough memory to complete it fully.
   To ensure that menus are always correct and yet responsive to the
user, which general approach would the ideal application framework take:

   a. The programmer should call one or more menu updating methods from
each point in the program that may have invalidated the menus. In turn,
these methods would update menus by systematically examining the current
state of the session.
   b. The programmer should register changes in the current state with a
menu bar handling object, which would backtrack to determine what was
affected and perform the update.
   c. Something other than a or b.


   The programmer can make dialogs within ResEdit or within a custom
dialog builder. Two dialog classes exist, one for each application. The
existence of two dialogs classes is hampering development of the
framework.
   ResEdit dialogs require more actual coding, but are simpler in
structure, and require simple dialog items. Dialogs from the custom
dialog builder are adequate for serious dialogs, and they are automatic
in that you put values in and get values out. However, the behavior of
the custom dialogs can only easily be changed from within the dialog
builder, and the dialog item classes must be much more involved.
   Further development of either dialog class can only be done at the
expense of the other, in that one class needs dialog item classes to be
simple, and the other needs them to be complex. Which class would the
ideal application framework develop further? Or would you?


   Say the user goes to make a new document. For whatever reason, memory
runs out and the document has only partly instantiated itself. Some
internal structures are instantiated, and yet some are not.
   To ensure that all memory is returned, that any created windows are
destroyed, and so forth, which general approach would the ideal
application framework take:

   a. The document's construction method should be responsible for the
destruction of whatever internal structures had already been created
when memory ran out.
   b. The document's destruction method should destroy all of the
internal structures and take necessary precautions against destroying
structures that were not yet created when the construction method
failed.
   c. Something other than a or b.


   Say the framework uses some preferences internally, the settings of
which are best set by the user rather than the programmer. For instance,
what speed at which to scroll, whether to check for font number clashes,
whether to do internal optimizations at idle time, or any one of several
other tradeoffs.
   To ensure that the user is given adequate control over these settings
without getting in the way of the programmer, what would the ideal
application framework do:

   a. Leave it to the programmer to provide the user a way to change
these preferences within their own preferences dialogs, if they want to
have them.
   b. Include a preferences command and dialog as a default, leaving it
to the programmer to override this behavior if they wish.
   c. Something other than a or b.


   Say the framework itself is to be released as shareware via the net,
but the author wishes to physically distribute documentation and
software to those who do not have access to either the net or the
modeming community at large.
  To ensure that the general Macintosh community can get the package,
which route would the ideal application framework take:

   a. Sell the package through APDA and user groups.
   b. Distribute a book to bookstores, with the software.
   c. Distribute a package to software distributors and retailers.
   d. Something other than a, b, or c.


   Theus {[e-mail], Portland, Oregon, USA, [phone]}

+++++++++++++++++++++++++++

From: [e-mail] (Martin Minow)
Date: 22 Jun 92 13:16:23 GMT
Organization: Apple Computer Inc., Cupertino, CA


[e-mail] asks several interesting questions:

1. How to handle menu item enabling. I generally do this by having a
single UpdateMenus() function and a global Boolean gUpdateMenus that
is set TRUE by any action routine that changes application state and
FALSE by UpdateMenus(). The main event loop calls UpdateMenus whenever
the flag is TRUE. There are other possible solutions; the Think Class
Library offers a similar mechanism that might be simpler to implement.

2. Error recovery (such as memory errors when creating a new document).
Here, I've been using the TRY/CATCH/ENDTRY model from the Think Class
Library (a similar library is available, I believe, in MPW). Any routine
that may fail with partial success adds its own error handler. For example:
    void ThisFunction() {
        Ptr    foo = NULL;
        Ptr    bar = NULL;
        TRY {
            foo = NewPtr(123); FailNIL(foo);
            bar = NewPtr(456); FailNIL(bar);
            SomeOtherFunction(foo, bar);
        }
        CATCH {        /* Error handler    */
            if (foo != NULL) DisposPtr(foo);
            if (bar != NULL) DisposPtr(bar);
        }
        ENDTRY;
        DisposPtr(foo);
        DisposPtr(bar);
    }
Here, any failure in the TRY {} block (either an allocation error or
a failure in SomeOtherFunction() will transfer control to the CATCH {}
block which cleans up its mess and, automatically, fails to the caller
of ThisFunction(). If everything succeeds, the code following ENDTRY
is executed, and the function returns normally. I found that this greatly
simplifies my programming model.

3. Preferences: some, such as window position, can be saved automatically.
Others should be in a preferences dialog. Look at some well-written
applications for examples; there are no easy answers.

Good luck.

Martin Minow
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Mimir Reynisson)
Date: 23 Jun 92 11:45:38 GMT

The best way I've discovered to do about menu enabling is to have
a mechanism that is automatically called on the activation of
new windows and when something occurs that "might" change the menus.

This mechanism automatically enables all menus and menu items before
calling your function or method or whatever, in which you disable the
inappropriate items. This makes for quite neat menu updateing and doesnt
require any global variables. Also this method frees you from the bother
of remembering what was enabled and disabled last time, since everything
is automatically enabled.

P.S.: Everything could be automatically disabled as well. But then a slight
bug or failure on your behalf could leave the Quit option disabled ;)

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik (High Priest of SSSM))
Date: 26 Jun 92 03:02:14 GMT
Organization: Secret Society of Software Mungers

As much as possible, with as little overhead as possible.

There are tradeoffs with a full hierarchical design, and with a flat
multi-object design. I'm of the opinion that developers need more
than one uniform, single framework. There's a need for a huge framework
which handles extremely complex views (MacApp, future stuff). And
there's a place for TCL with more light-weight views and less overhead.

And I would even state that there's a place for special template
frameworks, one for background apps (that's simple, I will whip one
together tonight just for the sake of it), one for (AE) server purposes,
one specialized in QuickTime/QuickDraw GX usage,  for trap patching,
one for DAL/data entry use, document based framework, and so on.

I would also like to see developers writing more standalone components,
which would do one single thing well, and could be implemented anywhere
as part of other frameworks. I'm trying to justify more time for DTS
engineers doing something similar over here just now. No wonder I work
late nowadays :-).

Cheerios,
Kent

---------------------------

From: [e-mail] (Andrew Ormsby)
Subject: Prototyper - summary of responses
Date: 22 Jun 92 10:00:32 GMT
Organization: CS Dept, University of Wales, Aberystwyth

Some time ago, I posted  a message asking for views on "Prototyper", a
product of Now Software (and formerly of Smethers Barnes). I'm
particularly interested in using Prototyper as a means of allowing
students to develop slick-looking applications reasonably quickly and
without having to read and understand the whole of Inside Macintosh.

Opinions on Prototyper seem pretty widely divided between those who
regard it as useless and others who think it is a really a Good Thing.
One person says that AppMaker looks like a better bet. Others say
AppMaker is not as good. I also have some garbled information about
"Marksman".

I'm still not much the wiser and my attempts to get some product
literature about Prototyper (including getting in touch with Apple UK)
have met with no success whatsoever. I can only assume that these
people aren't interested in selling their software.

Summarised messages follow.
- --

Andy Ormsby, [e-mail]


> From: [e-mail] (Dana S Emery)
>
> There is no way to avoid intimate IM knowledge (dont forget the Technotes)
> if one is to do anything nontrivial with a mac, the OS is just
> too intrusive.
>
> I used v 1.0 of Prototyper (smethers-barnes) and wouldnt commend that to
> my worst enemy.  The present v 3.? promises to be a lot cleaner, but..
>
> Consider AppMaker, it supports Think C/Pascal with TCL (object oriented
> class library).
>
> The problem with many CASE tools is that the integration hooks are not always
> automated, and any redaction of the work done by the CASE tool implies a
> major job of total re-integration.  This was the primary failing of Prototyper
> v1.0.
>
> I think you would be better off useing an interactive language, which would
> have a delberatly RISC'ish design (well, metaphorically speaking) to reduce
> the load on your students.
>
> The rule of thumb for serious Mac development is that it takes at least 2
> years of experience for an energetic neo.  I had 12 years on mainframes and
> minis, doing lotsa stuff, including disk drivers, using Fortran, Basic,
> Assembler, Mary, Pascal and TECO, and it took me about a year to get IM
> purchased and digested.
>
> The COST of IM is about to skyrocket, as a revised edition (15 vols) is
> going to press.  I think Apple may have taken this DTP thing to heart,
> and has decided to make money as a publisher.
>
> From [e-mail] Tue Jun  2 18:09:11 1992
> From: <[e-mail]>
> Subject:     Re: Prototyper -- anyone use it?
>
> I have used it alot, and I don't think that a regular lay person can
> use it without references to Inside Mac. The code produced is OK,
> more so on version 2.1 than 3.0 (I still use 2.1, since 3.0's code
> is much more convoluted) but without knowing the details of how things are
> done, there is not way you can modify the output for your purposes.
> Its a great teaching tool tho. You CAN of course use it to produce a
> dummy app, that does nothing without effort. Using it to produce an app
> that does something useful, requires that you alter many pieces of code
> and you have thorough knowledge of IM since it handles various tasks in
> fairly non-standard ways.
> Hope this helps.
> G.V.R.
>
> From [e-mail] Tue Jun  2 15:41:55 1992
> Newsgroups:   comp.sys.mac.programmer
> Organization: Iowa State University, Ames, IA
>
> i have used prototyper for about 2 years and it is
> really nice.  It would be a good item for your
> students to use.  it is easy to use and produces
> as you say really slick applications.
> robert thornburg                [e-mail]
> department of biochemistry      [phone] PH
>    and biophysics               [phone] FAX
> iowa state university
> ames, iowa 50011
>
>
> From: Danny William McCampbell <[e-mail]1>
> Message-Id: <[e-mail]>
> Subject: Re: Prototyper -- anyone use it?
> Organization: University of Tennessee Computing Center
>
> I have the old version of ProtoTyper and it is real good.  I heard
> the new version though is totally awesome!  I am trying to save my
> money and get it myself.
>
> --
> Danny McCampbell
> UT Computing Center
> [e-mail]
>
> From: Kent P Miller <[e-mail]>
> Subject: Re: Prototyper -- anyone use it?
>
> In article <[e-mail]> you write:
> >I'm interested in the "Prototyper" application, from Now Software,
> >Inc., which appears in the current APDA catalogue.
>
> Andy,
>
> I wouldn't order Prototyper.  Now doesn't support it anymore.  There is a
> update out from the guy who wrot Prototyper originally that is called
> Marksman, but I've never seen it.
>
> Also, do not buy AppMaker.  Its generated code is really bad.  I had the
> new version (1.5) and some code I generated with it crashed.  If anyone
> recommended it to you, email me for more details.
>
> Kent
>
>
> From: [e-mail]-analysis-ltd (Sak Wathanasin)
> Subject: Re: Prototyper -- anyone use it?
>
> > I'm interested in the "Prototyper" application, from Now Software,
> > Inc., which appears in the current APDA catalogue.
>
> > Can anyone who uses it, or has used it in the past, offer any comments?
> > What are the limitations of the approach?
>
> Prototyper is dead; do not buy 3.0. It seems to be pretty buggy. The developer
> of Prototype has produced a new tool called Marksman (he fell out with the
> distributor or something).
>
> > Could students use it to
> > produce reasonably slick-looking Macintosh applications without having
> > to read the contents of Inside Macintosh?
>
> You'll have to read Inside Mac eventually...
>
> Sak Wathanasin
> Internet: [e-mail]
>
> From: Rob Mitchell <[e-mail]>
> Subject: Re: Prototyper
>
> Hi,
>
>     I used Prototyper for a while to demo screens to customers.
>
>     I found the code it generated to be "not so good" in
>     terms of readability, etc.
>
>     I've switch to AppMaker by Bowers Development Co.  The
>     only feature (so far) that I miss is the "Quick Preview"
>     in Prototyper.
>
> Rob
>
> From: [e-mail] (Stepan Riha)
> Subject: Re: Prototyper -- anyone use it?
>
> Andy,
> I've played around with Prototyper a few years back and was rather disapointed
> in its implementation and the code it generated (back then I was using Pascal).
> Then again, I'm quite particular about the look, design and efficiency of my
> programs, and the latter two may not be of much concern to your students.
> The generated code did help me, however, to get an idea of how a Mac applica-
> tion should be written.
> Again, this was about 3 years ago, so a new version may be better.
> A good thing about Prototyper is that it generates code for C and Pascal for
> different compilers, specifically for MPW and THINK.
>
> I know that at the University of Texas at Austin, the Software Engineering
> class sometimes uses Prototyper. Sometime they use MacApp.  When I took it
> we used HyperCard.
>
> Another class I took at UT (Software-Hardware Interfacing) used THINK C and
> a book called "The Macintosh Programming Primer" (I think) that was an excel-
> lent book for people with C experience that were writing their first Mac app-
> lications.  The examples were well chosen and THINK C was explained pretty
> well, too.
>
> Good Luck,
>
>     Stepan
>
>
>
> From [e-mail] Sun Jun  7 13:00:06 1992
> From: Kent P Miller <[e-mail]>
> Subject: Re: Prototyper -- anyone use it?
>
> Andy,
>
> since I mailed you about Prototyper, I obtained some additional info:
>
> (about MarksMan,  the Prototyper replacement)
>
>             Marksman* - right on target
>
> Interface designer and source code generator for Apple Macintosh
> programs.
>
> Menus, Color & B/W Windows, Modeless Dialogs, Modal Dialogs, Alerts.
> Menu Editor, including hierarchical menus.
> Color and B/W Controls. Buttons,  Checkboxes,  Radio buttons,  Static
> Text,  Edit Text,  Pictures, Icons, Sicns, Popup menus, Scrolling lists,
> Palettes,  Rectangles and HotSpots,  Lines, Scrollbars.
> Plugins - Custom Buttons, Toggles, and Sliders (Your own designs,
> sources  the program.
>  included).
> Plug simulator that instantly allows you to see what the end
> program will look like, without having to code or compile the program.
> This simulation is instantanous and can be instantly called upon to see
> the program design as it is taking place.  You can create part of your
> interface design, instantly simulate it and try it out, modify it,
> simulate and y  ie
>
> All the available user intereaeleyecoa
> needed to pre iaomHnnaasefe
> availabftsugtlteoms.am
> suo  afeenf  optho
> cooedftitu ectuWsd
> CDEFs).
>
[this looks interesting, but the rest of the message is garbled and I
haven't been able to get any more information. -- aro]

+++++++++++++++++++++++++++

From: [e-mail] (Peter Creath)
Date: Mon, 22 Jun 92 18:49:50 CDT
Organization: Cube Technologies


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Andrew Ormsby) writes:
> > Prototyper is dead; do not buy 3.0. It seems to be pretty buggy. The developer
> > of Prototype has produced a new tool called Marksman (he fell out with the
> > distributor or something).

Yup, the author sent the company a beta and they released it.  He
got mad and left.  Now he writes Marksman, which (I just heard this
morning) has been updated to 2.0.  (Marksman 1.0 = Prototyper 3.0,
and there's really very little difference between the two).


- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]           become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

---------------------------

End of C.S.M.P. Digest
**********************